home *** CD-ROM | disk | FTP | other *** search
/ Pascal Super Library / Pascal Super Library (CW International)(1997).bin / LIBRARY / BPL70N16 / README.DOC < prev    next >
Text File  |  1994-08-29  |  21KB  |  419 lines
  1.      Borland-Pascal 7.0 Runtime Libary Update - Release 1.6   29-AUG-1994
  2.  
  3.  
  4.      ********************************************************************
  5.  
  6.      IMPORTANT NOTE: THIS IS THE FINAL VERSION OF MY FAST LIBRARY
  7.      REPLACEMENT FOR BP/TP 7.0, EXCEPT IF SOMEONE FINDS A SERIOUS
  8.      BUG IN THIS VERSION THAT I WOULD FIX, OF COURSE. IT SEEMS THAT
  9.      BP 8.0 IS JUST AROUND THE CORNER, SO FURTHER WORK ON BPL70Nxx
  10.      WOULDN'T MAKE MUCH SENSE. THERE WILL PROBABLY BE NO ENHANCED
  11.      LIBRARY FOR BP 8.0, AS I DO NOT HAVE THE TIME ANYMORE FOR THIS
  12.      KIND OF PROJECT.
  13.  
  14.      ********************************************************************
  15.  
  16.  
  17.      Welcome to BPL70N16.ZIP, a collection of fast replacement libraries
  18.      for your Turbo Pascal 7.0 / Borland Pascal 7.0 compiler. There are
  19.      three libraries in this package, a real mode library (TURBO.TPL), a
  20.      DOS protected mode library (TPP.TPL), and a Windows library (TPW.TPL).
  21.      Every file is a complete replacement for the original library bearing
  22.      the same name that came with your Pascal compiler. Due to the many
  23.      optimizations in the replacement libraries, many programs compiled
  24.      with these libraries will run faster. For more detailed information
  25.      on possible performance improvements, see the file PERFORM.DOC. Only
  26.      performance information for real mode and DOS protected mode programs
  27.      can be provided at the moment.
  28.  
  29.      Those users already familiar with my previous project, the fast
  30.      replacement library for Turbo Pascal 6.0 (distributed as TPL60N19.ZIP),
  31.      may be disappointed that not all the features of that program have
  32.      been included in BPL70N16.ZIP yet. I don't have much time at the moment,
  33.      but still wanted to provide a BP 7.0 version of my library as soon as
  34.      possible. So I decided to port the performance relevant stuff first
  35.      and work on the other aspects later.
  36.  
  37.      The libaries in BPL70N16 maintain 99.9% compatibility with the original
  38.      libraries. Differences are mostly caused by bug fixes and enhancements.
  39.      Some bugs from the original libraries supplied by Borland have been
  40.      eliminated, but there can be no guarantee that new ones have not crept
  41.      in. Most of the code in the BPL70N16.ZIP libraries was ported from the
  42.      latest version of my fast replacement library for Turbo Pascal 6.0,
  43.      TPL60N19.ZIP, which has been proven to be a stable and reliable product.
  44.  
  45.      If you discover any bugs, or have other comments, please let me know.
  46.      My email and snail mail addresses are given below. Although I am under
  47.      severe time constraints, I will try as hard as possible to fix any bugs
  48.      reported in as short a time as possible.
  49.  
  50.      The legal conditions under which Borland is distributing the source code
  51.      of the Borland Pascal 7.0 run-time libraries are not entirely clear to me.
  52.      To stay on the safe side, I assume that they are the same as for the RTL
  53.      source for the TP 6.0 compiler. Under these conditions, I am not allowed
  54.      to distribute modified source modules from the library. I may only
  55.      provide the binaries to third parties. However, some of the modules in
  56.      the BPL70N16.ZIP libaries do not contain a single line of code written
  57.      by Borland and are written entirely by me. I am including the source for
  58.      these modules for your reference. The source of the arithmetic routines
  59.      can be found in the file ARISOURC.ZIP. The source code of most of the
  60.      string routines is contained in the file STRSOURC.ZIP. The code of the
  61.      arithmetic and string routines is hereby released into the public domain.
  62.      You may use it in your own programs under the condition that you do not
  63.      include it into a commercial product. Parties interested in commercial
  64.      use of my code should contact me at my address below.
  65.  
  66.  
  67.      Original library code is Copyright (C) 1983,92 Borland International
  68.  
  69.  
  70.      New / additional library code is Copyright (C) 1988-1994 Norbert Juffa
  71.  
  72.  
  73.      Until October 1994:
  74.  
  75.      Norbert Juffa, Wielandtstr. 14, 76137 Karlsruhe, Germany
  76.      Internet: s_juffa@iravcl.ira.uka.de
  77.  
  78.      Thereafter:
  79.  
  80.      Norbert Juffa, 460 Navaro Way #201, San Jose, CA 95134, USA
  81.      Internet: norbert@iit.com
  82.  
  83.  
  84.  
  85.      Contents of this document:
  86.  
  87.      I.   Capabilities of RTL replacement
  88.      II.  Revision History
  89.      III. References
  90.  
  91.  
  92.  
  93.      I. Capabilities of RTL replacement
  94.      ==================================
  95.  
  96.  
  97.      General note:
  98.  
  99.      BPL70N16 provides you with optimized libraries, it does not enhance
  100.      the code produced by the Borland Pascal compiler. Thus, only code
  101.      that uses many library calls can be expected to experience significant
  102.      performance advantages. Library calls are made by BP 7.0 to operate
  103.      on LONGINTs, STRINGs, REALs, SETs, perform heap operations such as
  104.      allocating and deallocating memory (New, Dispose, GetMem, FreeMem),
  105.      as well as to perform other tasks. One exception where BPL70N16 speeds
  106.      up your code although no calls to optimized library routines are
  107.      made is floating-point applications using a 287 or 387 coprocessor.
  108.  
  109.      If want to speed up your applications even further than can be
  110.      accomplished by using BPL70N16, you might want to look at the
  111.      "Sally TPU peephole optimizer" (SPO for short) written by Morten
  112.      Welinder (terra@diku.dk). Unlike BPL70N16, this program is not in
  113.      the public domain, but Morten grants free use of the program for
  114.      personal, non-commercial use. SPO is a peephole optimizer that aims
  115.      at optimizing the code produced by the Pascal compiler. Peephole
  116.      optimizations means that the optimizer looks at a rather small
  117.      collection of machine instructions at a time and replaces certain
  118.      sequences it finds with optimized code. A TPU-optimizer speeds up
  119.      those parts of a program that can't be enhanced by a replacement
  120.      library and vice versa. So it might be a good idea to combine both
  121.      tools to get the best performance out of your BP 7.0 programs. The
  122.      SPO optimizer is currently distributed as a file SPO120.ZIP. It
  123.      should be available from all ftp-sites that carry BPL70N16 and in
  124.      particular can be downloaded from garbo.uwasa.fi, which is the upload
  125.      site for the program. Please note that this is not intended to be
  126.      an endorsement of the program. Rather, the info provided should be
  127.      thought of as being a service to those users of BPL70N16 who want
  128.      to speed up their programs even further than possible by using
  129.      BPL70N16.
  130.  
  131.  
  132.      Improvements in SYSTEM module
  133.      -----------------------------
  134.  
  135. o    REAL type software arithmetic operations now comply with ANSI/IEEE
  136.      Standard 754-1985 for Binary Floating Point Arithmetic [1,2] as much
  137.      as possible. Note that REAL arithmetic by design differs from the
  138.      standard in many ways, especially available numeric formats, value
  139.      set, and available operations. The rounding mode implemented here
  140.      is "round to nearest or even" as specified by the standard. Add,
  141.      Subtract, Multiply, Squaring, Division, and Square Root deliver
  142.      exact results with regard to this rounding mode, as demanded by the
  143.      standard. Conversions from REAL to LONGINT and from EXTENDED to REAL
  144.      use rounding to nearest or even, as specified in the standard. Correct
  145.      implementation of above features was tested with the PARANOIA test
  146.      program [3]. The correctness of basic REAL arithmetic functions has
  147.      also been tested against the coprocessor/emulator EXTENDED format
  148.      with the program FUN1_TST. The EXTENDED format carries approximately
  149.      19 decimal digits of precision. This description applies to all three
  150.      libraries in the package.
  151.  
  152. o    REAL arithmetic operations have been sped up. Speed-up for SQRT varies
  153.      between a factor of 11 for a 8086 and 30 for a 486DLC. FRAC now executes
  154.      at twice the original speed and speed-up is between 50% and 100% for
  155.      SIN, COS, ARCTAN, LN, EXP and division (2.8x speed up for division on
  156.      80386). Overall numeric processing power using REAL arithmetic increases
  157.      by about 52% for an 8086 and by 85% for an Cyrix 486DLC as measured
  158.      by the WHETSTONE benchmark [4,5]. This description applies to all three
  159.      libraries, but the actual values cited are for the real mode library
  160.      TURBO.TPL and may be different for the other libraries. In general,
  161.      DOS protected mode and Windows programs tend to be slower than real mode
  162.      programs by 5-50%.
  163.  
  164. o    Overall accuracy of REAL arithmetic transcendental functions has been
  165.      improved as indicated by Cody&Waite's ELEFUNT tests [6]: DLOG, DEXP,
  166.      DATAN, DSIN. Correct argument reduction ensures that relative error
  167.      over the whole argument range does not exceed 1.9e-12 for Exp, 2.8e-12
  168.      for Arctan, and 2.7e-12 for Ln. These values have been determined
  169.      by comparing the function returns of the REAL transcendental functions
  170.      to the values computed on a Cyrix 83D87 coprocessor for the EXTENDED
  171.      format. For Sin and Cos, relative error is also in the above range
  172.      when the argument is reasonably small (e.g. in range -100..100) and
  173.      not very close to an integer multiple of 0.25*Pi. The error of the
  174.      transcendental functions expressed in ULPs (units in the last place)
  175.      over the whole argument range does not exceed 1.6 ULPs for Exp, 1.8
  176.      ULPs for Arctan, and 2.2 ULPs for Ln. This description applies to all
  177.      three libraries in the package.
  178.  
  179. o    Execution of coprocessor floating point computations using an 80287 or
  180.      80387 has been accelerated. For these coprocessors, NOPs will be inserted
  181.      before every floating point instruction converted from an emulator
  182.      interrupt instead of WAITs. As a result of this optimization, an
  183.      improvement in execution speed of about 10% has been observed running the
  184.      Lawrence Livermore Loops (LLL) [7] on a Cyrix 83D87, the improvement
  185.      for the WHETSTONE benchmark on the 83D87 is similar. Maximum performance
  186.      gain for tight loops (e.g. fractal computation) by this measure is about
  187.      22%.
  188.  
  189. o    On 80287XL, 80387, 80486DX, or compatible chips the Sin and Cos functions
  190.      take advantage of the FSIN and FCOS instructions of these coprocessors,
  191.      speeding up these functions by almost a factor of two. As a side effect,
  192.      there is also some improvement in accuracy as measured by the DSIN test
  193.      program from the ELEFUNT test suite. Also, the Arctan function takes
  194.      advantage of the increased argument range of the FPATAN function. These
  195.      optimizations result in another 19% increase in WHETSTONE power, so
  196.      that the total combined speedup over the original library is about 30%
  197.      for this benchmark using a 387 coprocessor.
  198.  
  199. o    STRING operations are faster, especially for longer strings. Most
  200.      dramatic increase is in the INSERT function, with execution times
  201.      reduced to up to one fourth compared with the original version of
  202.      the RTL. Faster string operations cause 7% performance increase for
  203.      the DHRYSTONE [8,9] benchmark on a 8086.
  204.  
  205. o    Improved speed of random number generation. Random for REAL numbers
  206.      is 10-20% faster, Random for EXTENDED numbers is 5% faster. Due to
  207.      the improvements in the uniform distribution of integer random numbers,
  208.      there is a decrease in the speed of integer random number generation
  209.      of about 5%.
  210.  
  211. o    Binary to decimal conversions used in Str and Write procedures have
  212.      been sped up by up to 70% for integers (BYTE, SHORTINT, INTEGER,
  213.      WORD, LONGINT), up to 5% for REAL numbers and about 3% for EXTENDED
  214.      numbers.
  215.  
  216. o    Improved speed of LONGINT arithmetic for 8086..80286. Division enjoys
  217.      a 30% reduction of execution time on 8086. On 386 and 486 type CPUs,
  218.      the code used in BPL70N16 may be slower than that used by the original
  219.      library, which uses 32 bit register operations, while BPL70N16 uses
  220.      only 16 bit operations, however very cleverly. For most applications
  221.      you will not note any drop in LONGINT performance on 386/486 machines
  222.      by using BPL70N16.
  223.  
  224. o    Several of the functions of the heap manager have been tuned, resulting
  225.      in 7%-11% faster operation for these routines, depending on the CPU used.
  226.      This note applies only to the real mode heap manager in TURBO.TPL!
  227.  
  228. o    Set functions have been sped up by a few percent, but the add variable
  229.      range operation may be up to eight times as fast.
  230.  
  231. o    Several bugs of the original RTL supplied by Borland have been fixed:
  232.  
  233.      The original routines to perform LONGINT shifts provide the wrong results
  234.      when the program runs on a 386 or 486 type processor and the shift count
  235.      exceeds 16. This has been fixed by replacing all LONGINT routines with
  236.      my own code. My code doesn't use 386 specific instructions and foregoes
  237.      the speed advantage offered by using 32-bit register operations. For all
  238.      programs but a very few you will not notice any drop in performance on a
  239.      386-486 machine, though. Borland has fixed this bug in the mean time and
  240.      versions 7.01 and later of the compiler no longer have it.
  241.  
  242.      GetDir now correctly returns a run-time error 15 (invalid drive)
  243.      when called with a non existent drive. Differing from the original,
  244.      it also signals all errors reported by DOS as run-time errors. E.g.
  245.      when applied to a floppy drive that does not contain a floppy, it
  246.      will now return run-time error 152 (drive not ready), where previously
  247.      it would incorrectly signal successful completion of the operation
  248.      (InOutRes = 0).
  249.  
  250.      For programs compiled with $N+, only true INFs are printed out as
  251.      INF where with the original library some NaNs are also printed as
  252.      INF. Correct operation can be tested with the INFBUG program.
  253.  
  254.      REAL arithmetic EXP functions no longer signals overflow when
  255.      called with small arguments, but underflows to zero instead as it
  256.      should.
  257.  
  258.      Denormals in EXTENDED computations no longer cause an invalid state
  259.      on a 8087 coprocessor when being converted to true zeros. Consistency
  260.      between register contents and tag bits is now asserted. Removal of
  261.      this bug can be tested with the BUG87 program.
  262.  
  263.      Denormals in EXTENDED format are now correctly converted to decimal
  264.      strings by the Str and Write routines. The original routines print
  265.      EXTENDED precision denormals as zero. Note that BP 7.0 supports
  266.      EXTENDED denormals only if your machine has an 80287XL, 80387, 80486
  267.      or equivalent. On the 8087 and Intel's original 80287 coprocessor
  268.      denormals are only supported for the SINGLE and DOUBLE formats. Correct
  269.      printing of extended precision denormals can be checked with the
  270.      program DENORMTS.
  271.  
  272.      Program initialization routine now tries to prevent that programs
  273.      compiled with the $G+ (286 code generation) switch are run on 8086
  274.      and 8088. The checks done are not 100% safe, but catch most of these
  275.      cases, displaying the message "CPU > 8086 required" and aborting the
  276.      program with a return code of 254 ($FE) instead of letting it crash.
  277.      Note that this check lets programs compiled with $G+ run on 80186 and
  278.      V20/V30 processors, since they have the ability to execute all 80286
  279.      real mode instructions produced by Turbo Pascal. This note applies
  280.      only to real mode programs, as DOS protected mode and Windows programs
  281.      will not run on anything less than a 286 anyhow.
  282.  
  283.  
  284.  
  285.      Improvements in CRT module
  286.      --------------------------
  287.  
  288. o    Bug fix in routine DirectWrite. The method used to prevent "snow"
  289.      when writing directly to a CGA graphics card was not entirely safe.
  290.      When used in a heavily interrupted program (e.g. serial communication
  291.      as a background task), it would not always write during the time
  292.      when scanning was in the invisible parts of the screen. The method
  293.      used now is 100% save and is even faster, since it takes advantage
  294.      of the horizontal and vertical retrace periods, as opposed to the
  295.      old method which only used the horizontal retrace time. The new
  296.      routine has been tested successfully on an original IBM-CGA card.
  297.  
  298.  
  299.  
  300.      II. Revision History
  301.      ====================
  302.  
  303. o    Changes since version 1.5, dated 03-18-1994
  304.  
  305.      It was brought to my attention by Sotiris Tsibonis
  306.      (Sotiris.Tsibonis@p2.f204.n410.z2.fidonet.org) that the enhanced
  307.      Upcase function in previous versions of this library caused
  308.      problems when used in countries where the national code page
  309.      differs sustantially from the standard code page 437, e.g.
  310.      Greece. I have therefore changed the Upcase function back to
  311.      the original functionality and am providing the extended upcase
  312.      function as a separate .OBJ file that can be linked as needed.
  313.      The extended function is named UpCase437. It converts the following
  314.      characters to upper case that are not converted by the normal
  315.      Upcase function: ä,ü,ö,å,æ,é,ñ,ç. To use the function UpCase437,
  316.      copy the file UCASE437.OBJ to your work directory and include
  317.      the following two lines in your program:
  318.  
  319.        {$L UCASE437.OBJ}
  320.  
  321.        FUNCTION UpCase437 (C: CHAR): CHAR; FAR; EXTERNAL;
  322.  
  323.  
  324.  
  325. o    Changes since version 1.4, dated 01-07-1994
  326.  
  327.      When fixing the bug in the Str function in the Windows library
  328.      TPW.TPL for machines without a math coprocessor in version 1.4,
  329.      I accidentally broke the code for machines that do have a math
  330.      coprocessor. Thanks to Siegfried Voessner (VOESSNERQFTUG.AC.AT)
  331.      for reporting this bug.
  332.  
  333.  
  334.  
  335. o    Changes since version 1.3, dated 10-24-1993
  336.  
  337.      Fixed bug in the Str function in the Windows library TPW.TPL that
  338.      caused the Str function to abort with run time error 207 when passed
  339.      a non-zero argument on a PC without a math coprocessor. The bug
  340.      was caused by the inability of Windows' coprocessor emulator to
  341.      correctly emulate the FBSTP instruction. Many thanks to Eduardo
  342.      Mauro (eduardo.mauro@bbs816.mandic.onsp.br) for reporting this bug
  343.      and helping me to track it down.
  344.  
  345.  
  346.  
  347. o    Changes since version 1.2, dated 05-20-1993
  348.  
  349.      Fixed bug in the code of the Instr function. The previously provided
  350.      code did not work correctly when compiled with the $G+ option. Thanks
  351.      to Flurin Honegger (honegger@urz.unibas.ch) for reporting this bug.
  352.  
  353.  
  354.  
  355.      Changes since version 1.1, dated 03-15-1993
  356.  
  357. o    Fixed bug in the Write and WriteLn routines of the CRT unit. Due to
  358.      this bug, these routines could not function properly on a Hercules
  359.      Graphics Card or other monochrome display. Thanks to Miha Vitorovic
  360.      (Miha.Vitorovic@f108.n380.z2.fidonet.org) for reporting this bug.
  361.  
  362.  
  363.  
  364.      Changes since version 1.0, dated 03-10-1993
  365.  
  366. o    Fixed bug in LONGINT and REAL Val routine. Val erroneously returned
  367.      the wrong value or an error code for syntactically correct strings.
  368.      Thanks to Dennis J. Basiaga (dennisb@dancer.cc.bellcore.com), who was
  369.      the first to report this bug.
  370.  
  371.  
  372.  
  373.      Version 1.0, original release.
  374.  
  375.  
  376.  
  377.      III. References
  378.      ===============
  379.  
  380. [1]  IEEE: IEEE Standard for Binary Floating-Point Arithmetic.
  381.      SIGPLAN Notices, Vol. 22, No. 2, 1985, pp. 9-25
  382.  
  383. [2]  IEEE Standard for Binary Floating-Point Arithmetic.
  384.      ANSI/IEEE Std 754-1985.
  385.      New York, NY: Institute of Electrical and Electronics Engineers 1985
  386.  
  387. [3]  Karpinski, R.: Paranoia: A Floating-Point Benchmark.
  388.      Byte, February 1985, pp. 223-235
  389.  
  390. [4]  Curnow, H.J.; Wichmann, B.A.: A synthetic benchmark.
  391.      Computer Journal, Vol. 19, No. 1, 1976, pp. 43-49
  392.  
  393. [5]  Wichmannn, B.A.: Validation code for the Whetstone benchmark.
  394.      NPL Report DITC 107/88, National Physics Laboratory, UK, March 1988
  395.  
  396. [6]  Cody, W.J.; Waite, W.: Software Manual for the Elementary Functions.
  397.      Englewood Cliffs, NJ: Prentice Hall 1980
  398.  
  399. [7]  McMahon, H.H.: The Livermore Fortran Kernels: A Test of the Numerical
  400.      Performance Range.
  401.      Technical Report UCRL-53745, Lawrence Livermore National Laboratory,
  402.      December 1986, p. 179
  403.  
  404. [8]  Weicker, R.P.: Dhrystone: A Synthetic Systems Programming Benchmark.
  405.      Communications of the ACM, Vol. 27, No. 10, October 1984, pp. 1013-1030
  406.  
  407. [9]  Weicker, R.P.: Dhrystone Benchmark: Rationale for Version 2 and
  408.      Measurement Rules.
  409.      SIGPLAN Notices, Vol. 23, No. 8, August 1988, pp. 49-62
  410.  
  411. [10] 387DX User's Manual, Programmer's Reference. Intel 1989
  412.  
  413.  
  414.      Note:
  415.  
  416.      PARANOIA, DHRYSTONE, WHETSTONE, LLL, and ELEFUNT source code is
  417.      available from NETLIB@ORNL.GOV
  418.  
  419.